This invention relates to data processing systems, methods and computer program products and more particularly to database systems, methods and computer program products.
Relational databases are widely used to store data in data processing environments. As is well known to those having skill in the art, in a relational database, data is addressed based on its relationship to other data rather than its actual location in the database. The relationships among data in the relational database may be indicated using relationship keys. For example, each data element of an owner class may have a primary key associated therewith, and each data element of a member class may include a foreign key that points to the primary key of the data element that owns the member element. The design and operation of relational databases are well known to those having skill in the art and need not be described in detail herein.
Object-oriented programming systems, methods and computer program products are also widely used in data processing environments. As is well known to those having skill in the art, object-oriented programming systems, methods and computer program products are composed of a large number of xe2x80x9cobjectsxe2x80x9d. An object is a data structure, and a set of operations or functions that can access the data structure. Objects having identical data structures and common behavior can be grouped together into, and collectively identified as, a class. In an object-oriented computing environment, the data is processed by requesting an object to perform one of its methods. Inheritance relationships also may exist between two or more classes such that a first class may be considered a parent of a second class and the second class may be considered a child of the first class. The data structure of the child class includes all of the attributes of the parent class. The design and operation of object-oriented programming systems, methods and computer program products are well known to those having skill in the art and need not be described in detail herein.
Object-oriented computing environments are now being used to form object-oriented transaction systems that can be flexible and user-friendly. As is well known to those having skill in the art, a transaction generally refers to a logical group of changes to one or more objects that are performed in an atomic manner. In other words, either all operations within the transaction are performed, or none of them are performed. By using a transactional approach, all changes to an object by a user within the scope of a transaction are made first to an internal copy of the object, without actually updating the persistent, stored object itself. The user may eventually decide whether to permanently commit the changes encompassed by the transaction, or whether to discard them. If the user chooses to commit, then the objects in persistent storage are updated. If the user chooses to discard the changes, the persistent storage is left unchanged.
Object-oriented transaction systems may be used in enterprise applications that reflect complex business processes, so that users can navigate freely between different elements of the user interface. For example, the user may wish to have multiple windows for one application open on a display at the same time. Users of such applications may expect that they can switch from processing information in one window to processing information in a different window without having to take special precautions to ensure consistency of the data between the different windows. An object-oriented transaction system is described in co-pending application Ser. No. 09/223,986 entitled xe2x80x9cTechnique for Managing Enterprise JavaBeans(trademark) which are the Target of multiple Concurrent and/or Nested Transactionsxe2x80x9d to Nally et al., filed Dec. 3, 1998, and assigned to the assignee of the present invention, the disclosure of which is hereby incorporated herein by reference.
Relational databases generally include referential integrity constraints for maintaining consistency of the database. These constraints generally require database tore and delete operations to be executed in a specific order. Unfortunately, this order may not match the order in which objects are created, modified or deleted within an object-oriented transaction. Moreover, the database referential integrity constraints generally do not map to the logical object relationships in a consistent manner. Referential integrity constraints generally are enforced based on the key information, such as which entity is referring and which entity is being referred to with a relational foreign key. This key information may have more than one possible transformation when mapped to object relationships. Therefore, it may be difficult to deduce an order in which trees of objects need to be stored to or deleted from the relational database, based upon the application event flow or the object relationship logical directions.
Accordingly, it may be difficult to interface an object-oriented transaction system to a relational database such that database operations are properly ordered or sequenced upon completion of a transaction by the object-oriented transaction system. In order to interface an object-oriented transaction system to a relational database, while maintaining the relational database referential integrity constraints, customized coding of operation ordering may be provided in the object-oriented transaction system. However, such custom coding may be time-consuming and may consume up to 30% or more of a project""s resources. See the publication entitled xe2x80x9cScalable Object-Persistence Frameworksxe2x80x9d, Journal of Object-Oriented Programming, November/December 1998, pages 18-24 by the present inventors and Hill. Alternatively, referential integrity constraint enforcement may be disabled in the relational database. Unfortunately, if the referential integrity constraints are disabled in the relational database, the entire relational database may become corrupted and internally inconsistent.
It is therefore an object of the present invention to provide systems, methods and computer program products that can interface an object-oriented transaction system with a relational database.
It is another object of the present invention to provide systems, methods and computer program products that can interface an object-oriented transaction system with a relational database while preserving the relational database referential integrity constraints.
These and other objects are provided, according to the present invention by systems, methods and computer program products that automatically order objects corresponding to database operations that are performed on a relational database upon completion of a transaction by an object-oriented transaction system. The objects in the completed transaction are clustered into groups of objects to be inserted into the relational database, objects to be deleted from the relational database and objects to be updated in the relational database. The objects to be inserted into the relational database are ordered according to an insert precedence of the objects into the relational database to thereby define an insert order. The objects to be deleted from the relational database are ordered according to a delete precedence of the objects from the relational database to thereby define a delete order. The objects to be inserted into the relational database are inserted into the relational database in the insert order. Then, the objects to be updated in the relational database are updated in an arbitrary order. Finally, the objects to be deleted from the relational database are deleted from the relational database in the delete order.
The precedences between different database operations form complex prerequisite trees. However, it has been found according to the present invention, that these prerequisites need not be completely resolved in order to be able to determine the correct order for operation execution. Rather, the prerequisites need only be resolved among the insert operations and among the delete operations, but not across different operation types. The operations can then be executed in three phases: first the insert operations, then the update operations and last, the delete operations.
According to another aspect of the present invention, the same operations may be used to resolve the precedences for insert and update operations. For example, to order the objects to be deleted from the relational database, associations among the objects to be deleted are identified. A current object to be deleted is defined and it is determined if the current object to be deleted has delete precedence over an associated object to be deleted. The current object to be deleted is ordered ahead of the associated object to be deleted if the current object to be deleted has delete precedence over the associated object to be deleted. The current object to be deleted is deleted behind the associated object to be deleted if the current object to be deleted does not have delete precedence over the associated object to be deleted. These operations may be repeatedly performed for remaining objects associated with the current object to be deleted. These operations also may be recursively performed for each object that is associated with the current object to be deleted that is ordered ahead of the associated object to be deleted.
Associations among the objects to be deleted may be identified by identifying current and associated objects in the objects to be deleted, identifying foreign keys and primary keys in the objects to be deleted and identifying constraints in the relational database between pairs of foreign keys and primary keys. Delete precedence may be determined by determining if a foreign key of the current object to be deleted refers to a primary key of an associated object to be deleted. If there is a constraint identified between the foreign key of the current object to be deleted and the primary key of the associated object to be deleted, then the current object to be deleted has delete precedence over the associated object to be deleted. In contrast, if no constraints are identified between the foreign key of the current object to be deleted and the primary key of the associated object to be deleted, then the current object to be deleted does not have delete precedence over the associated object to be deleted. The same operations may be performed for objects to be inserted.
Upon completion of these operations, the order of insert and delete operations to be performed on the relational database automatically corresponds to the referential integrity constraints for the relational database. Accordingly, upon completion of a transaction by an object-oriented transaction system, database operations are automatically performed on a relational database in an order that will maintain the relational database referential integrity constraints. Custom coding of operation ordering for each specific application need not be provided, and the database need not be corrupted by the sequence of operations that were performed by the object-oriented transaction system during a transaction.